1. Field of the Invention
The invention disclosed broadly relates to the field of client-server computing and/or server centric computing, and more particularly relates to the field of desktop administration and network management tools.
2. Description of the Related Art
The field of client-server computing continues to grow. Networks such as LANs, Intranets, the Internet and the World-Wide Web are based on client-server topologies. The growth of client-server computing has lead to an increased demand on the administration of networks by administrators.
For each client, the administrators must set each shared applications the client will have access to, define the desktop layout and security, and other client configurations. As an example, one application from Microsoft Corporation called Outlook often requires client user configuration guided by an installation wizard. However, many computer users may not know what to enter for the wizard or may provide incorrect values, so network administrators have historically made use of logon scripts to provide a pre-configured environment.
The term “logon script” is the set of executables or scripts or batch files that a client system runs during logon, which may be locally stored by the client and retrieved from a server that defines the resources, security and the configuration for each client. Operating systems 306 such as Microsoft Windows NT4.0/2000/2003 provide some settings for applications that can be configured automatically during the clients' boot-up and login in the client default profile or through system policies. However, some of the settings for applications and resources, such as mapping a drive letter to a network resource or connecting to a network printer or automatic software deployment, which fall between the cracks of what Windows NT allows administrators to configure automatically for each client. For these settings, custom logon scripts files or custom executables have been used.
Logon scripts have been around with products such as Novell Inc.'s Netware™ products for years. The Novell products are not the only scripting products available, and other scripts are possible in operating system 306 such as Windows NT 4.0. Logon scripts are very useful tools in the network environment. Logon scripts automatically run during the logon process and can help set up the client working environment by copying files, creating connections, and launching applications. The logon process can be summarized as the sequence events between the time a user enters their authentication information (e.g., userid and password) and the time the computer is ready to be used (e.g. the desktop is loaded and the user can begin work).
In fact, it is common today for most corporate networks to use logon scripts because they assist with centralized administration. However logon scripts are difficult to create, edit and administer. Also, logon scripts in certain environments such as Windows NT/2000/2003 can be assigned to a single user or multiple users.
Although these logon scripts are useful for helping to administer and manage networks, they are not without their shortcomings. One shortcoming with logon scripts today is that they are written in a special scripting language or DOS batch files and must be hand edited and debugged. The requirement to write and debug logon scripts across an enterprise network installation is time consuming and expensive. Accordingly, a need exists for a method and apparatus to provide a centralized configuration.
Another shortcoming with currently available solutions is that they are cumbersome to manage across several clients. To centrally manage clients, network administrators make use of batch files and scripts that are customized to each client. The process of managing custom batch files for each user and/or computer is tedious. Moreover, the currently available solutions such as logon scripting languages, cannot support the complex features of network administration. More complex feature such as group memberships, printer deployment, proxy server access, MS Office paths, service packs, anti-virus updates, policies and automatic Outlook/Exchange mail profile creation are not supported in many logon scripts. The administrators of large networks are then forced to make a difficult choice of either learning a more complex logon scripting language and attendant debugger or forego supporting more complex features centrally in the network administration. Accordingly, a need exists for a method and an apparatus to provide the administration of a plurality of clients across a network the ability to able to handle more complex support features without the need to debug a single line of code.
Still another shortcoming with currently available solutions is that there is no method to validate if a desired setting is proper for a given user on a given client system. Stated differently, certain resources should not be set if a given group, a selected operating system and a selected connection method is not met. For example, a logon script may request a certain drive letter for the client, say drive letter “O” to be mapped to a particular resource, say a CD ROM on a server, however this can only happen if the user of the client is a member of a particular group. Today, no method exists to verify one or more local run-time environmental conditions on a client. The solution employed by Microsoft in its Windows Server 2000 and 2003 line of products is the use of Group Policy Objects at the server. This Group Policy Object solution although useful, is not able to make determinations of local run-time environments on the client. Therefore it is not possible to determine such things using group policies as host address, subnets, MAC, primary groups, whether terminal services is running, what third party applications are running, and whether the client system is a portable or desktop hardware configuration. This type of granularity of the client system local run-time environment is not available. Accordingly, a need exists for a method to permit clients to validate local-run time environments prior to the application of one or more desktop settings on a client system.
Yet still another shortcoming with currently available solutions and management applications is the inability to perform updates based on an event or activity. For example, it would not be useful to try to connect to a network drive on a portable device such as laptop if the network is not available. Warning messages that the network is not available often confuses users rather than assist them.
Still, another shortcoming with currently available solutions and management applications is the inability to use wildcards such length invariant wildcards such as “*” i.e., the asterisk or position specific wildcards such as i.e., “?” the question mark. The use of wildcards enables easier management of a group of computers, such as clients, within in a predetermined IP address range.